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Security Requirements for BGP Path Validation 


Abstract 
This document describes requirements for a BGP security protocol 
design to provide cryptographic assurance that the origin Autonomous 
System (AS) has the right to announce the prefix and to provide 
assurance of the AS Path of the announcement. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7353. 
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document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Origin validation based on Resource Public Key Infrastructure (RPKI) 
[RFC6811] provides a measure of resilience to accidental 
mis-origination of prefixes; however, it provides neither 
cryptographic assurance (announcements are not signed) nor assurance 
of the AS Path of the announcement. 


This document describes requirements to be placed on a BGP security 
protocol, herein termed "BGPsec", intended to rectify these gaps. 


The threat model assumed here is documented in [RFC4593] and 
[RFC7132]. 


As noted in the threat model [RFC7132], this work is limited to 
threats to the BGP protocol. Issues of business relationship 
conformance, while quite important to operators, are not security 
issues per se and are outside the scope of this document. It is 
hoped that these issues will be better understood in the future. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 
be interpreted as described in RFC 2119 [RFC2119] only when they 
appear in all upper case. They may also appear in lower or mixed 
case, without normative meaning. 


2. Recommended Reading 


This document assumes knowledge of the RPKI [RFC6480] and the RPKI 
Repository Structure [RFC6481]. 
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This document assumes ongoing incremental deployment of Route Origin 
Authorizations (ROAs) [RFC6482], the RPKI to the Router Protocol 
[RFC6810], and RPKI-based Prefix Validation [RFC6811]. 


And, of course, a knowledge of BGP [RFC4271] is required. 
3. General Requirements 
The following are general requirements for a BGPsec protocol: 
ZL A BGPsec design MUST allow the receiver of a BGP announcement 
to determine, to a strong level of certainty, that the 


originating AS in the received PATH attribute possessed the 
authority to announce the prefix. 


3.2 A BGPsec design MUST allow the receiver of a BGP announcement 
to determine, to a strong level of certainty, that the received 
PATH attribute accurately represents the sequence of External 
BGP (eBGP) exchanges that propagated the prefix from the origin 
AS to the receiver, particularly if an AS has added or deleted 
any AS number other than its own in the PATH attribute. This 
includes modification to the number of AS prepends. 


33:3 BGP attributes other than the AS_PATH are used only locally, or 
have meaning only between immediate neighbors, may be modified 
by intermediate systems and figure less prominently in the 
decision process. Consequently, it is not appropriate to try 
to protect such attributes in a BGPsec design. 


34 A BGPsec design MUST be amenable to incremental deployment. 
This implies that incompatible protocol capabilities MUST be 
negotiated. 


33389 A BGPsec design MUST provide analysis of the operational 
considerations for deployment and particularly of incremental 
deployment, e.g., contiguous islands, non-contiguous islands, 
universal deployment, etc. 


3.6 As proofs of possession and authentication may require 
cryptographic payloads and/or storage and computation, likely 
increasing processing and memory requirements on routers, a 
BGPsec design MAY require use of new hardware. That is, 
compatibility with current hardware abilities is not a 
requirement that this document imposes on a solution. 


Sal A BGPsec design need not prevent attacks on data-plane traffic. 


It need not provide assurance that the data plane even follows 
the control plane. 
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A BGPsec design MUST resist attacks by an enemy who has access 
to the inter-router link layer, per Section 3.1.1.2 of 
[RFC4593]. In particular, such a design MUST provide 
mechanisms for authentication of all data, including protecting 
against message insertion, deletion, modification, or replay. 
Mechanisms that suffice include TCP sessions authenticated with 
the TCP Authentication Option (TCP-AO) [RFC5925], IPsec 
[RFC4301], or Transport Layer Security (TLS) [RFC5246]. 


It is assumed that a BGPsec design will require information 
about holdings of address space and Autonomous System Numbers 
(ASNs), and assertions about binding of address space to ASNs. 
A BGPsec design MAY make use of a security infrastructure 
(e.g., a PKI) to distribute such authenticated data. 


It is entirely OPTIONAL to secure AS SETs and prefix 
aggregation. The long-range solution to this is the 
deprecation of AS_SETs; see [RFC6472]. 


If a BGPsec design uses signed prefixes, given the difficulty 
of splitting a signed message while preserving the signature, 
it need not handle multiple prefixes in a single UPDATE PDU. 


A BGPsec design MUST enable each BGPsec speaker to configure 
use of the security mechanism on a per-peer basis. 


A BGPsec design MUST provide backward compatibility in the 
message formatting, transmission, and processing of routing 
information carried through a mixed security environment. 
Message formatting in a fully secured environment MAY be 
handled in a non-backward compatible manner. 


While the formal validity of a routing announcement should be 
determined by the BGPsec protocol, local routing policy MUST be 
the final arbiter of the best path and other routing decisions. 


A BGPsec design MUST support ‘transparent’ route servers, 
meaning that the AS of the route server is not counted in 
downstream BGP AS-path-length tie-breaking decisions. 


A BGPsec design MUST support AS aliasing. This technique is 
not well defined or universally implemented but is being 
documented in [AS-MIGRATION]. A BGPsec design SHOULD 
accommodate AS /’/migration’ techniques such as common 
proprietary and non-standard methods that allow a router to 
have two AS identities, without lengthening the effective AS 
Path. 
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If a BGPsec design makes use of a security infrastructure, that 
infrastructure SHOULD enable each network operator to select 
the entities it will trust when authenticating data in the 
security infrastructure. See, for example, [LTA-USE-CASES]. 


A BGPsec design MUST NOT require operators to reveal more than 
is currently revealed in the operational inter-domain routing 
environment, other than the inclusion of necessary security 
credentials to allow others to ascertain for themselves the 
necessary degree of assurance regarding the validity of Network 
Layer Reachability Information (NLRI) received via BGPsec. 

This includes peering, customer/provider relationships, an 
ISP’s internal infrastructure, etc. It is understood that some 
data are revealed to the savvy seeker by BGP, traceroute, etc., 
today. 


A BGPsec design MUST signal (e.g., via logging or SNMP) 
security exceptions that are significant to the operator. The 
specific data to be signaled are an implementation matter. 


Any routing information database MUST be re-authenticated 
periodically or in an event-driven manner, especially in 
response to events such as, for example, PKI updates. 


Any inter-AS use of cryptographic hashes or signatures MUST 
provide mechanisms for algorithm agility. For a discussion, 
see [ALG-AGILITY]. 


A BGPsec design SHOULD NOT presume to know the intent of the 
originator of a NLRI, nor that of any AS on the AS Path, other 
than that they intend to pass it to the next AS in the path. 


A BGPsec listener SHOULD NOT trust non-BGPsec markings, such as 
communities, across trust boundaries. 


UPDATE Security Requirements 


The following requirements MUST be met in the processing of BGP 
UPDATE messages: 


4L 


A BGPsec design MUST enable each recipient of an UPDATE to 
formally validate that the origin AS in the message is 
authorized to originate a route to the prefix(es) in the 
message. 
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4.2 A BGPsec design MUST enable the recipient of an UPDATE to 
formally determine that the NLRI has traversed the AS Path 
indicated in the UPDATE. Note that this is more stringent than 
showing that the path is merely not impossible. 


4.3 Replay of BGP UPDATE messages need not be completely prevented, 
but a BGPsec design SHOULD provide a mechanism to control the 
window of exposure to replay attacks. 


4.4 A BGPsec design SHOULD provide some level of assurance that the 
origin of a prefix is still ‘alive’, i.e., that a monkey in the 
middle has not withheld a WITHDRAW message or the effects 
thereof. 


4.5 The AS Path of an UPDATE message SHOULD be able to be 
authenticated as the message is processed. 


4.6 Normal sanity checks of received announcements MUST be done, 
e.g., verification that the first element of the AS_PATH list 
corresponds to the locally configured AS of the peer from which 
the UPDATE was received. 


4.7 The output of a router applying BGPsec validation to a received 
UPDATE MUST be unequivocal and conform to a fully specified 
state in the design. 


5. Security Considerations 


If an external "Security infrastructure" is used, as mentioned in 
Section 3, paragraphs 9 and 17 above, the authenticity and integrity 
of the data of such an infrastructure MUST be assured. In addition, 
the integrity of those data MUST be assured when they are used by 
BGPsec, e.g., in transport. 


The requirement of backward compatibility to BGP4 may open an avenue 
to downgrade attacks. 


The data plane might not follow the path signaled by the control 
plane. 


Security for subscriber traffic is outside the scope of this document 
and of BGP security in general. IETF standards for payload data 
security should be employed. While adoption of BGP security measures 
may ameliorate some classes of attacks on traffic, these measures are 
not a substitute for use of subscriber-based security. 
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